Web Parts are an encapsulation of functionality and information that can be dropped onto a web page as a unit. By themselves, Web Parts are “islands” of functionality and information which have a fixed amount of value. For example, a page could have two Web Parts, a list of team members and a list of activities for individuals on the team. The value each Web Part provides to a user viewing the Web Parts is limited to the distinct information the Web Part presents. However, much greater value can be achieved by connecting the Web Parts together to support communication or interaction between the connected Web Parts. In the above example, the two Web Parts could be connected in a manner which allows the team members' Web Part to filter information from the activities' Web Part, whereby only the activities of team members are retrieved from the activities' Web Part.
Prior Web Part connection systems allowed Web Parts to share information between one another by hard wiring the connection between the two Web Parts. The Web Parts could share information if the two Web Parts had intimate knowledge of one another. This typically required that the same software developer develop the code for these Web Parts. These prior systems allowed for limited flexibility in sharing information between Web Parts. Furthermore, these prior systems did not allow end users to connect Web Parts, which the end user created, to suit individual needs.
Yet another prior Web Part connection system developed a limited number of methods to allow Web Parts to connect to one another and to pass information. This prior system passed an object to a client. The object provided a series of utility-type methods for creating and converting URL code to allow Web Parts to be connected together. However, this system still required that the Web Parts have intimate knowledge of one another before connecting and passing information. Furthermore, an end user relied on developers to create Web Parts which could be connected and pass information among one another. Additionally, developers who created Web Parts did not adhere to any standard method for creation. The failure to adhere to a standard limited the ability to share information between Web Parts created by different developers.
In view of the foregoing, there is a need in the art for a method to allow end users to connect Web Parts via a graphical user interface instead of relying on code written specifically for each connection. This greatly increases the flexibility of Web Parts and puts control in the hands of the end user. In addition, there is a need in the art for a method to connect Web Parts that comply with a standard so that Web Parts not developed by the same person can be connected. Furthermore, there is a need in the art for the ability to connect a Web Part residing on one page to a Web Part residing on a different page.